home *** CD-ROM | disk | FTP | other *** search
/ Columbia Kermit / kermit.zip / newsgroups / misc.19950528-19950726 / 000062_news@columbia.edu_Mon Jun 5 13:18:58 1995.msg < prev    next >
Internet Message Format  |  2020-01-01  |  6KB
  1. Received: from apakabar.cc.columbia.edu by watsun.cc.columbia.edu with SMTP id AA16931
  2.   (5.65c+CU/IDA-1.4.4/HLK for <kermit.misc@watsun.cc.columbia.edu>); Mon, 5 Jun 1995 09:19:17 -0400
  3. Received: by apakabar.cc.columbia.edu id AA07043
  4.   (5.65c+CU/IDA-1.4.4/HLK for kermit.misc@watsun); Mon, 5 Jun 1995 09:19:13 -0400
  5. Path: news.columbia.edu!watsun.cc.columbia.edu!fdc
  6. From: fdc@watsun.cc.columbia.edu (Frank da Cruz)
  7. Newsgroups: comp.protocols.kermit.misc
  8. Subject: Re: Kermit MAC??
  9. Date: 5 Jun 1995 13:18:58 GMT
  10. Organization: Columbia University
  11. Lines: 105
  12. Message-Id: <3qv083$6r1@apakabar.cc.columbia.edu>
  13. References: <3qnon9$asf@steel.interlog.com> <3qtbvi$a4o@news.doit.wisc.edu> <3qtfnp$gca@apakabar.cc.columbia.edu> <3qtt35$gji@news.doit.wisc.edu>
  14. Nntp-Posting-Host: watsun.cc.columbia.edu
  15. Apparently-To: kermit.misc@watsun.cc.columbia.edu
  16.  
  17. In article <3qtt35$gji@news.doit.wisc.edu>,
  18. Glenn R. Howes  <grhowes@students.wisc.edu> wrote:
  19. >As for a more fully featured Kermit tool, a) there are
  20. >at least 4 commercial tools of varying functionality, b) the
  21. >freely available one is good enough for most people, c) most
  22. >freeware communications programmers seem to be concentrating
  23. >on TCP/IP applications. If any young programmer is reading,
  24. >writing one will take about 3 months of weekends, buy 
  25. >Frank's book "Kermit: A File Transfer Protocol", get the
  26. >current specs from their ftp site at Columbia, invest
  27. >in "Inside the Macintosh Communication Toolbox" and get the
  28. >specs on CTB 1.1 which should be on the apple ftp site. Also,
  29. >don't write it by cutting and pasting, write it from scratch
  30. >using the protocol specs, you'll be happy you did later.
  31. >
  32. Perhaps.  But the real Kermit protocol engine is already inside
  33. Mac Kermit.  80% of a real VT320 emulator is there too.  90%
  34. of the Kermit script language is there too.  The character-set
  35. translation is there too.  I can see why people who live in
  36. the Macintosh universe would want something less monolithic and
  37. more modular, but that is putting a rather fine point on it.
  38. We already have something that almost works, and that shares
  39. code with literally hundreds of other Kermit implementations
  40. and an incredibly diverse range of platforms.  The point being
  41. that if separate Kermit tools, translation tools, VTxxx tools,
  42. etc, were constructed, they would immediately become orphans.
  43. There is one and only one shared nucleus of common code.  We
  44. simply can't afford to maintain lots of code bases.
  45.  
  46. Anybody in the Macintosh programming community who would like
  47. to see Macintosh Kermit reach fruition, by whatever means, is
  48. encouraged to take up where our last generation of volunteers
  49. left off.
  50.  
  51. >Then base it around OpenDoc which is extremely cross platform
  52. >and will protect us from the code bloat of Microsoft and OLE.
  53. >
  54. More "standards"...  I have to admit I have not even looked at
  55. OpenDoc.  Why should I?  Without even knowing what it is, let me
  56. take a guess: it is some new "standard" put forward by yet another
  57. "consortium" of "major players" which is so complex that the only
  58. way anyone could incorporate "compliance" with it into one's
  59. applications would be by licensing proprietary libraries and
  60. bloated development environments, and which, no matter how
  61. portable it is said to be, will not come close to covering the
  62. 400+ platforms covered by C-Kermit, the code base for Macintosh
  63. Kermit.  And which probably requires megabytes of memory and disk,
  64. etc etc.  Maybe I'm jaded, but don't these "standards" pop up and
  65. then fall by the wayside on a yearly basis?  Am I the only one who
  66. sees the entire software industry grinding to a halt as it chases
  67. the holy grail of the latest self-proclaimed "standard" from
  68. Microsoft, Apple, IBM, or various consortia that fill the trade
  69. publications with glorious proclamations of future cooperation and
  70. openness, only to melt away before anybody has noticed?
  71.  
  72. >Otherwise, look at NetScape, which seems to be perfectly at
  73. >home whether it is in Windows, MacOS, or X. 
  74. >
  75. Of course, we are looking very carefully at the successful
  76. cross-platform apps.
  77.  
  78. >Maybe that is your problem, no Mac programmer worth his bits 
  79. >wants to write a program that looks like it would be at home 
  80. >in DOS land.
  81. >
  82. Mac Kermit might have a somewhat crude user interface, but from
  83. the very beginning it has always been a true Macintosh point-
  84. and-click interface.  Recently we added on C-Kermit's command-line
  85. interface in an optional "command window".  Why?  Primarily for
  86. scripting and dialing.  Not only can script programs now be run in
  87. Mac Kermit, but they are the very same script programs that run in
  88. UNIX, VMS, OS/2, AOS/VS, VOS, OS-9, and on the Amiga and the Atari
  89. ST, and to a large extent also DOS and Windows.  Thousands of
  90. sites have a huge investment in their installed base of Kermit
  91. scripts, and Mac Kermit's command-line interface "leverages" (as
  92. they say) that investment to the large installed base of Macs.
  93.  
  94. That's not to say that Mac Kermit's graphical interface can or
  95. should not be improved.  It needs a LOT of work.  Most of the work
  96. that is needed could be done by a competent Mac programmer in a
  97. weekend.  But we have not had a competent Mac programmer working
  98. on the project in several years.
  99.  
  100. There is also a handful of show-stopper bugs in Mac Kermit, of the
  101. sort that could only be found and fixed by a good Mac programmer,
  102. one who is familiar with the quirks of the many Mac OS releases,
  103. hardware platforms, and ROMs.
  104.  
  105. So the situation seems to be: countless thousands of people at
  106. thousands of sites WANT Mac Kermit to reach release level, but no
  107. Macintosh programmer will to touch it because it is not "pure".
  108.  
  109. >Unfortunately, a lot of the software I unwittingly buy is 
  110. >built with just this mentality. [coding to the lowest common
  111. >denominator]
  112. >
  113. Portability is not a "mentality" -- it's the way we provide code
  114. that works on more platforms than, probably, any other nontrivial
  115. program on earth.  A good Mac programmer, such as yourself, who
  116. took on Mac Kermit would no doubt do a bang-up job, using all the
  117. available tools and features in such a way as not to compromise
  118. the quality for Mac users, but still maintaining the portability
  119. of the protocol and other common modules to the other platforms.
  120.  
  121. - Frank